One of the most difficult problems facing the minicomputer architect is that of sufficient address space. Address fields must be potentially large enough so that all of the data and procedures for a process can be directly addressed without recourse to slow, complex memory mapping schemes, while at the same time retaining the architectural simplicity and minimal hardware cost which characterize the minicomputer.
A minicomputer is usually organized around a fixed relatively small memory word size, typically 12 to 18 bits, and uses that word size as a common controlling parameter throughout its architecture. Operands, instructions and addresses are all usually of that same size. Frequently, both for reasons of cost, and for purposes of address manipulation, addresses and operands even share the same operating registers.
The use of such an organization can be very cost-effective, but has the serious deficiency that it creates a de facto limit on memory size, by requiring that addresses be no longer than operands. If memory word/register size is 16 bits, the most common size, then addresses are constrained to a maximum size of 65,536 words.
This has proven to be a severe limitation in recent years, for both functional and economic reasons. Tasks and applications tend to expand in scope, requiring additional memory; operating systems and higher-level languages, while improving system functionality, have a major impact on memory size. Reduced memory costs have also fueled user requirements for large memories. Memory costs decreased at the rate of 26% to 41% per year; since users tend to buy constant dollar amounts of memory, it follows that the amount of address space typically required doubles every two to three years.
Numerous examples exist of minicomputer architectures which have accepted this de facto limit on memory size, and then been found wanting as the damand for larger memories increased.
Because of software and hardware development costs, studies for new minicomputer architecture usually require that the architecture support an entire family of computers. This means that the new architecture must support not only the system with a large address base and elaborate operating systems, but also the small OEM-oriented system where speed and minimum program size are essential. Equally essential, however, is the necessity not to impair the software mobility, the ability to transport programs from machines at one end of the family to machines at the other.
A particular objective of any architecture is to develop a method of dealing with addressing which would not be tied to word size, but be open-ended, clean and consistent in all members of the family. Address size should be of no concern to the programmer, and should not impair program mobility from one member of the family to another.
If, by way of example, a 16-bit word size represented the largest address size, memory size would be limited to 64K words; sufficient for present applications, but obviously inadequate for future needs. To have a reasonable certainty of being able to satisfy memory requirements for the life of a computer family, a maximum memory size should be at least 8 to 10 million words, thus implying an address size of at least 23 bits. However, addresses larger than 16 bits require 2 words of memory to hold them, and take twice as long to load and store. The large-system user, running under an operating system, would not object to this burden, since it would significantly reduce the amount of storage management and overlay activity which, of necessity, accompanies a small address space. The small-system, OEM user would be unwilling to incur this time/space penalty, however, since his address space requirements are smaller, and his application is typically more cost/performance sensitive.
Examination of the nature and usage of addresses reveals some interesting properties, particularly in the ways in which they differ from other operands. All other operands are programmer visible, explicitly typed and sized structures, they are: bits, bytes, words or multi-words, etc. The programmer is aware of the size of the item he is dealing with and uses this characteristic in manipulating it. Addresses, however, are primarily the concern of the program assembler, and only of secondary interest to the programmer. He is chiefly interested in addresses as the names of structures, arrays and program locations. He wants to be able to assign names as required, and then use them wherever necessary, both for convenience and for ease of understanding. The last thing the programmer wants to do is to get immersed in address computation and manipulation. Address size is unimportant; as long as an address is "big enough" the programmer does not really care.
This consideration of the differences between addresses and other operands leads to a concept which is referred to as address size independence; a philosophy/architecture in which the size of addresses is essentially invisible to the programmer at the level of assembler source code, and is only apparent at the object code level.
Under this concept, the same source code can be assembled and run on any member of the family; however, the program assembler used to create object code for those members whose addresses are larger than 16 bits would be different from the program assembler used to create object code for the small members of the family. The large system program assembler would create two words of storage for each memory address in the code, the small system assembler only one.
Each system would receive object code containing addresses suitable to its hardware, while the programmer, operating at the level of the single source code from which both object codes are derived, would deal with addresses as tags and identities, in a non-size-specific fashion.
It is accordingly a primary object of the present invention to provide a data processing system having multiple length addressing modes.